I think De Villers suggestion using a CS Link gives more flexibility to
the SRC than using a CS Group. A CS Group implies that the SRC have to
tie multiple CSes to a single RS, whereas a Link is more a loosely
defined construct that allows the SRC to link different CSes across
RSes.

Taking the same consultation example below with A/B/C; if party C
resides on separate site it is likely to require a separate RS to record
party C. Using CS link, we now have a mechanism for the SRC to link the
relationship between the different segments of the call but are not
forced to group the CSes into a single RS.

An SRC can still model the same thing using a single CS out of the 3
parties with different received media streams and participants, but then
you are forced to use a single CS to model the parties and this is
undesirable when the parties are spread across sites. Having a link
between CSes allows the SRC to have the flexibility to define what is a
CS (from 3pcc perspective normally), and that seems to be a reasonable
solution to this problem.

Regards,
Henry 

> -----Original Message-----
> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On
> Behalf Of Paul Kyzivat
> Sent: Friday, October 22, 2010 12:26 PM
> To: De Villiers de Wet
> Cc: siprec@ietf.org; Leon Portman
> Subject: Re: [siprec] SIP Recording Metadata :Receivedvs RecordedMedia
> Streams
> 
> inline
> 
> On 10/22/2010 10:55 AM, De Villiers de Wet wrote:
> > Paul
> >
> >> Yes, perhaps CS Group is needed. Or maybe all of my case is
actually
> > one CS. We need to figure this out once and for all.
> >
> > Here also it depends from what perspective one wants to view a CS -
> from
> > the perspective of the customer (external party in a typicall call
> > center scenario), or from the perspective of the organization, or
> from
> > the perspective of a each particular monitored party - each one
gives
> a
> > different answer, and each one is correct, depending on what you're
> > interested in in a given situation.
> >
> > In general I think trying to force your case and similar cases into
a
> > single CS is asking for trouble.  A similar case is for example:
> >
> > - A in call with B
> > - C phones A - (call waiting feature enabled)
> > - A puts B on hold and speaks to B (conversation is not related to
> the
> > A<->B conversation at all)
> > - A<->C call ends
> > - A resumes call with B
> 
> I'm glad you brought up this case - I was going to.
> 
> > This should NOT be modeled as one CS, but on a SIP level it is very
> > similar to your case, except for the direction of the second call.
> And
> > in your example case, what if the content of the "consultation" call
> has
> > nothing to do with the original call?  On a SIP signalling level the
> SRC
> > would have nothing to be able to distinguish it from others.
> 
> Agreed. It would require some overt indication to distinguish these
> cases. Or else it might just be inferred after the fact.
> 
> > Now for transfer scenarios and conferences.  even here we have
> problems:
> >
> > Blind transfer:
> > 	- A in call with B (segment 1)
> > 	- A puts B on hold and performs a BLIND transfer to C (never
> > speaks to C)
> > 	- C in call with B (segment 2)
> > This arguably the best case for having a single CS for a non-simple
> call
> > from the organization's and B's perspective, but even here the
> > individual participant C was not involved in the CS during segment
1.
> >
> > Consult transfer
> > - A in call with B (segment 1)
> > - A puts B on hold, calls C and speaks to C (segment 2)
> > - A transfers call to C
> > - C in call with B (segment 3)
> >
> > What to do?  Instead of trying to create a combined entity (which
one
> is
> > correct), perhaps the SRC must just provide LINKING information
> BETWEEN
> > separate CSs for a SUCCESFUL transfer as above:
> > - have 3 separate CSs - CS1, CS2 and CS3
> > CS1 is linked to CS2 (A's perspective)
> > CS1 is linked to CS3 (B's perspective)
> > CS2 is linked to CS3 (C's perspective)
> 
> I'm certainly open to this as a solution.
> 
> > What about a failed transfer:
> >
> > Failed Consult transfer
> > - A in call with B (CS1)
> > - A puts B on hold, calls C and speaks to C (CS2)
> > - C refuses to take the call
> > - C in call with B (CS3)
> >
> > If the system knows the intention of the call to C was a transfer
> (e.g.
> > transfer button was pressed on phone to start a transfer sequence),
> then
> > it could still link CS1 to CS2, and CS1 to CS3.
> >
> > Linking info for conference call segments could be provided in a
> similar
> > manner as above.  Conferences have the added complexity of what to
do
> > when participants leave the conference - create a new CS or not?
> 
> My original intent was that the CS would continue, but that the
> Received
> Media Stream would change each time there was a participant change.
> 
> > Providing such LINKING information (as is done by some PBXs
currently
> in
> > CTI info) leaves it up to the SRS to decide how to group CSs
together
> > during recording or at playback time.
> 
> The linking info would be a reasonable way to accomplish this.
> 
> 	Thanks,
> 	Paul
> 
> > De Villiers
> >
> >
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Sent: 21 October 2010 19:48
> > To: Elwell, John
> > Cc: De Villiers de Wet; Leon Portman; siprec@ietf.org
> > Subject: Re: [siprec] SIP Recording Metadata :Received vs
> RecordedMedia
> > Streams
> >
> >
> >
> > On 10/21/2010 12:46 PM, Elwell, John wrote:
> >> But the RS would not necessarily tie those together. In some cases
> it
> > might, but in other cases the CSs might be recorded using separate
> RSs,
> > and in yet other cases a single RS might include some related CSs
and
> > many additional CSs.
> >
> > Yeah, all of that is possible.
> >
> >> Perhaps we need the concept of a CS Group. Note that we used to
have
> > an RS Group object, but we were not convinced of its benefit.
> However, a
> > CS Group might have some value in some circumstances. One word of
> > caution however, is that this again is an application concept, and
> SIP
> > will not necessarily give us sufficient information to group
together
> > related CSs reliably, particularly where 3PCC is used.
> >
> > Yes, perhaps CS Group is needed. Or maybe all of my case is actually
> one
> >
> > CS. We need to figure this out once and for all.
> >
> > Clearly identifying which CSs need to be grouped, or which dialogs
> > belong to the same CS, is in some sense an application problem.
> > I guess the choice is where this application logic resides:
> > - in the SRC
> > - in the SRS
> > - in some backend client of the recorded data
> >
> > If the logic is to be in the SRC, then we don't need to know how it
> > decides, but we need the proper metadata for it to record its
> decision.
> > And if done in the SRC it can only be done when the SRC has
> visibility
> > to all the things that need to be grouped.
> >
> > If the logic is in the SRS, or further back, then we probably don't
> have
> >
> > this kind of grouping representation in our metadata, but we need
> more
> > raw data for the backend processes to use to make that
determination.
> >
> > 	Thanks,
> > 	Paul
> >
> >> John
> >>
> >>> -----Original Message-----
> >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> >>> Sent: 21 October 2010 17:19
> >>> To: Elwell, John
> >>> Cc: De Villiers de Wet; Leon Portman; siprec@ietf.org
> >>> Subject: Re: [siprec] SIP Recording Metadata :Received vs
> >>> RecordedMedia Streams
> >>>
> >>>
> >>>
> >>> On 10/21/2010 11:55 AM, Elwell, John wrote:
> >>>> Paul,
> >>>>
> >>>> I am not convinced of the need for a retention period on
> >>> the RS. The RS is just a means of delivering  recording
> >>> material from for one or more CSs to the SRS, but thereafter
> >>> it can be forgotten. It makes no difference when you try to
> >>> replay, analyse or search recordings what RS it arrived over
> >>> - it is only the CS that is important. I see no need for
> >>> retaining information about an RS.
> >>>>
> >>>> One use case is the persistent recording case, where the RS
> >>> is more or less permanent and used to record multiple CSs.
> >>> For this reason too, I don't think a retention time makes
> >>> sense for an RS.
> >>>
> >>> OK, I get your point. But it then puts further emphasis on the
> proper
> >>> definition of CS. I'll reference the same example I have used
> >>> multiple
> >>> times:
> >>>
> >>> - customer in call with agent
> >>> - agent puts customer on hold
> >>> - agent makes consultation call with expert
> >>> - consultation call ends
> >>> - agent resumes call with customer
> >>>
> >>> Question is whether above is one CS or two.
> >>> Assuming the consultation call pertained to the customer
> >>> call, then they
> >>> should probably be treated as a unit for recording, playback,
> >>> retention
> >>> purposes.
> >>>
> >>> If these are one CS then there is no issue (on this point).
> >>> If they are two CSs, then currently the only thing we have to
> >>> tie them
> >>> together is the RS, and we would need to invent something else.
> >>>
> >>> 	Thanks,
> >>> 	Paul
> >>>
> >>>> John (as individual)
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> >>>>> Sent: 21 October 2010 15:08
> >>>>> To: Elwell, John
> >>>>> Cc: De Villiers de Wet; Leon Portman; siprec@ietf.org
> >>>>> Subject: Re: [siprec] SIP Recording Metadata :Received vs
> >>>>> RecordedMedia Streams
> >>>>>
> >>>>> We currently allow multiple CS per RS. ISTM that it makes a
> >>>>> lot of sense
> >>>>> to have a retention period per RS, and it *might* make
> >>> sense to have
> >>>>> separate retention periods per CS within and RS. After that,
> >>>>> I guess the
> >>>>> question is whether it makes sense to have separate retention
> >>>>> period per
> >>>>> received media stream. While its technically possible, I'm
> >>>>> with John in
> >>>>> questioning the utility.
> >>>>>
> >>>>> A lot of the other discussion about per-participant
> >>> retention periods
> >>>>> may just be application specific policy stuff about how to
> >>> choose the
> >>>>> retention periods for the things we will standardize.
> >>>>>
> >>>>> 	Thanks,
> >>>>> 	Paul
> >>>>>
> >>>>> On 10/21/2010 9:48 AM, Elwell, John wrote:
> >>>>>> (Chair hat on) It's getting hard to figure out who said
> >>>>> what in some of these threads.
> >>>>>>
> >>>>>> (Chair hat off) To me having a retention period applying to
> >>>>> the entire rocording of a CS makes sense. Any smaller degree
> >>>>> of granularity (whether it be party-based, media-type-based,
> >>>>> or whatever) does not make a lot of sense. I would want to
> >>>>> see very strong justification for anything other than per-CS.
> >>>>>>
> >>>>>> John
> >>>>>>
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: siprec-bounces@ietf.org
> >>>>>>> [mailto:siprec-bounces@ietf.org] On Behalf Of De Villiers de
> Wet
> >>>>>>> Sent: 20 October 2010 15:49
> >>>>>>> To: Paul Kyzivat; Leon Portman
> >>>>>>> Cc: siprec@ietf.org
> >>>>>>> Subject: Re: [siprec] SIP Recording Metadata :Received vs
> >>>>>>> RecordedMedia Streams
> >>>>>>>
> >>>>>>> below
> >>>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> >>>>>>> Sent: 18 October 2010 16:12
> >>>>>>> To: Leon Portman
> >>>>>>> Cc: siprec@ietf.org
> >>>>>>> Subject: Re: [siprec] SIP Recording Metadata :Received vs
> >>>>>>> RecordedMedia
> >>>>>>> Streams
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 10/17/2010 5:16 AM, Leon Portman wrote:
> >>>>>>>> Couple of comments:
> >>>>>>>>
> >>>>>>>> I still see use cases, where SRC has access to signaling
> >>>>>>> thus able to
> >>>>>>> extract metadata but does not have access to specific media
> >>>>>>> types: like
> >>>>>>> video is handled by special gateway.
> >>>>>>>
> >>>>>>> Do you expect that the SRC would have access to all the same
> >>>>>>> info as for
> >>>>>>>
> >>>>>>> a received media stream except for the media itself?
> >>>>>>>
> >>>>>>> Could we model that as a received media stream that is
> >>> permanently
> >>>>>>> paused? Or do we need to make provision in the model for a
> >>>>>>> "Non-Received
> >>>>>>>
> >>>>>>> Media Stream"?
> >>>>>>>
> >>>>>>>> Regarding retention parameters: it definitely belongs
> >>> to Received
> >>>>>>> Media because it is the resolution that SRS receives it. So
> >>>>>>> for example
> >>>>>>> SRS will not mix two Received Media streams into one
> >>> Recorded Media
> >>>>>>> stream if they have different retention attributes
> >>>>>>>
> >>>>>>> Makes sense.
> >>>>>>>
> >>>>>>> [DdW] The first part makes sort of sense ("belongs to
> >>>>> Received Media
> >>>>>>> because it is the resolution that SRS receives it"), but the
> >>>>>>> second part
> >>>>>>> of the sentence does not make sense to me: "SRS will not mix
> two
> >>>>>>> Received Media streams into one Recorded Media stream if
> >>> they have
> >>>>>>> different retention attributes" (although the latter is
> >>>>>>> probably an SRS
> >>>>>>> implementation issue).
> >>>>>>>
> >>>>>>> [DdW] If retention periods can be set per user, retention
> >>>>> periods can
> >>>>>>> differ between participants, and is therefore not an
> >>>>>>> attribute of CS as
> >>>>>>> a whole. BUT is it then not rather an attribute more closely
> >>>>>>> associated
> >>>>>>> with a participant than with the media of his/her speech?
> >>>>>>> Should an SRS
> >>>>>>> keep the recording of one side/direction of a SIP
> >>>>> telephone call for a
> >>>>>>> shorter period than the other if the retention attributes
> >>>>> differ? This
> >>>>>>> would render the recording unintelligible and useless after
> >>>>>>> applying the
> >>>>>>> retention rule to the 1 recorded media stream.
> >>>>>>>
> >>>>>>> [DdW] For example, let's say the requested retention period
> >>>>>>> for user A's
> >>>>>>> recordings is 1 year and for user B's recordings it is 5
> >>>>> years, and A
> >>>>>>> and B are involved in a CS that is recorded.  It would not
> >>>>>>> make sense to
> >>>>>>> delete the recording for A's media after 1 year, but keep the
> >>>>>>> recording
> >>>>>>> of user B's media for 5 years.  The SRS should have a rule (or
> >>>>>>> configurable option) on what to do if required retention
> >>>>>>> periods differ
> >>>>>>> for the participants in a call, e.g. the most natural rule
> >>>>> will be to
> >>>>>>> retain all the media for the CS for the longest of the
required
> >>>>>>> retention periods OR (my preference) to create two
> >>>>> Recording Sessions
> >>>>>>> for a CS - one for each (internal, monitored) participant.
> Then
> >>>>>>> participant A's recording of the CS can be managed separately
> and
> >>>>>>> independently from participant B's recording.
> >>>>>>>
> >>>>>>> [DdW] In summary I think user-associated retention parameters
> >>>>>>> are better
> >>>>>>> associated with a participant than with a media stream, while
> the
> >>>>>>> implementation of retention (rules to handle conflicts, RS
> >>>>> copies for
> >>>>>>> each participant, etc.) falls outside the scope of the
> standard.
> >>>>>>>
> >>>>>>> [DdW] Having said that, it could be the case that retention
> >>>>>>> periods are
> >>>>>>> based on some application-dependent classification, e.g.
> >>>>>>> whether it's a
> >>>>>>> Sales, Support or New Contract call, in which case
> >>>>> retention also DOES
> >>>>>>> apply on the CS level and not (only) on the participant or
> >>>>>>> media stream
> >>>>>>> level, and it must probably be taken into account in
> >>>>> conjunction with
> >>>>>>> user-associated retention periods.
> >>>>>>>
> >>>>>>> [DdW] Even though retention is very relevant for recording
> >>>>>>> systems, the
> >>>>>>> question could be asked whether retention parameters
> >>> really belong
> >>>>>>> explicitly in the SIPREC metadata model.
> >>>>>>>
> >>>>>>> 	Thanks,
> >>>>>>> 	Paul
> >>>>>>>
> >>>>>>>> Leon
> >>>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: siprec-bounces@ietf.org
> >>> [mailto:siprec-bounces@ietf.org] On
> >>>>>>> Behalf Of Paul Kyzivat
> >>>>>>>> Sent: Friday, October 15, 2010 3:17 PM
> >>>>>>>> To: Ram Mohan R (rmohanr)
> >>>>>>>> Cc: siprec@ietf.org
> >>>>>>>> Subject: Re: [siprec] SIP Recording Metadata :Received
> >>> vs Recorded
> >>>>>>> Media Streams
> >>>>>>>>
> >>>>>>>> inline
> >>>>>>>>
> >>>>>>>> On 10/14/2010 12:53 PM, Ram Mohan R (rmohanr) wrote:
> >>>>>>>>> Hi Team,
> >>>>>>>>>
> >>>>>>>>>       From the last interim meeting we had the following
> >>>>> open items on
> >>>>>>>>> Received and Recorded Media Streams
> >>>>>>>>>
> >>>>>>>>> Need for Recorded Media Stream block in the metadata model:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> --------------------------------------------------------------
> >>>>>>> ----------
> >>>>>>> -----
> >>>>>>>>>
> >>>>>>>>> Open Item 1:
> >>>>>>>>>
> >>>>>>>>> We received comments in the list/interim meeting that
> >>>>>>> certain aspects
> >>>>>>> of
> >>>>>>>>> media like how SRS stores media, keys used e.t.c may be
> >>>>> outside the
> >>>>>>>>> scope of SIPREC. I agree that what SRS does once it
> >>>>> receives media
> >>>>>>> may
> >>>>>>>>> be outside SIPREC scope.
> >>>>>>>>>
> >>>>>>>>> We may still need Recorded Media Stream block and have
> >>> attributes
> >>>>>>> like
> >>>>>>>>> retention time, force deletion as these values may be
> >>>>>>> passed from SRC
> >>>>>>>>> via SIPREC interface in the metadata. SRS can store the
these
> >>>>>>> attributes
> >>>>>>>>> in the model and can apply them to media.
> >>>>>>>>>
> >>>>>>>>> I would like to get the opinion from wider audience on
> >>> whether we
> >>>>>>> need a
> >>>>>>>>> Recorded Media Stream block before we decide to one
> >>> way or other
> >>>>>>>>
> >>>>>>>> Model will be simpler if we get rid of recorded media stream.
> >>>>>>>> But it seems we need some home for the attributes you
suggest.
> >>>>>>>> Could they be placed on the received media stream? I
> >>>>> think we need a
> >>>>>>>> better understanding of how the SRC will view things and
> >>>>> attempt to
> >>>>>>>> attach attributes such as retention time.
> >>>>>>>>
> >>>>>>>>> Open item 2:
> >>>>>>>>>
> >>>>>>>>> We discussed on whether the model should include all
> >>>>> media from CS,
> >>>>>>> only
> >>>>>>>>> those media for which recording was requested, or only
> >>>>> those media
> >>>>>>> for
> >>>>>>>>> which recording was requested and accepted.
> >>>>>>>>>
> >>>>>>>>> Is this really needed ? Does the wider team sees a value
> >>>>> in having
> >>>>>>> this
> >>>>>>>>> information ( about all media from CS) in the model ?
> >>>>>>>>>
> >>>>>>>>> When we say all the media from CS I suppose we are
> >>>>> referring to all
> >>>>>>> the
> >>>>>>>>> media that is accessible to SRC ?
> >>>>>>>>>
> >>>>>>>>> If we see a value in having it in the model, I think we
> >>>>>>> can represent
> >>>>>>>>> the same in the model .
> >>>>>>>>>
> >>>>>>>>> For e.g An SRC may offer to record audio/video streams
> >>> for a CS,
> >>>>>>> however
> >>>>>>>>> SRS may choose to accept only Audio. This information can
> >>>>>>> be modeled
> >>>>>>> by
> >>>>>>>>> having Received Media Stream block for each offered
> >>>>> media from SRC
> >>>>>>> and
> >>>>>>>>> Recorded media Stream block for only those that were
> >>>>>>> accepted by SRS.
> >>>>>>> In
> >>>>>>>>> this case the presence/absence of Recorded Media Stream
> >>>>>>> block in the
> >>>>>>>>> model corresponding to a Received Media Stream can
> >>>>> indicate whether
> >>>>>>>>> media was recorded or not.
> >>>>>>>>
> >>>>>>>> If the SRC offers the media, and the SRS refuses it,
> >>> then maybe no
> >>>>>>> more
> >>>>>>>> need be done. The SRS knows about it and chose to refuse
> >>>>> it. It can
> >>>>>>>> record that info if it wants.
> >>>>>>>>
> >>>>>>>> I guess the issue would be if the SRS then gets a full
> >>>>> complement of
> >>>>>>>> metadata for it, or if having refused the stream, it no
> >>>>> longer gets
> >>>>>>>> metadata. I guess we could cover that my requiring that
> >>>>> metadata be
> >>>>>>>> transmitted even for refused streams.
> >>>>>>>>
> >>>>>>>> I wonder if Leon was talking about a case where the media
> >>>>> isn't even
> >>>>>>>> available to the SRC. But in that case I'm not sure we can
> >>>>>>> expect the
> >>>>>>>> SRC to provide information about it.
> >>>>>>>>
> >>>>>>>> 	Thanks,
> >>>>>>>> 	Paul
> >>>>>>>> _______________________________________________
> >>>>>>>> siprec mailing list
> >>>>>>>> siprec@ietf.org
> >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> siprec mailing list
> >>>>>>> siprec@ietf.org
> >>>>>>> https://www.ietf.org/mailman/listinfo/siprec
> >>>>>>>
> >>>>>
> >>>
> >
> >
> >
> _______________________________________________
> siprec mailing list
> siprec@ietf.org
> https://www.ietf.org/mailman/listinfo/siprec

					
-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.